Subject: Guidelines for DLSw SIG

From: [email-masked]
Date: Mon, 26 Apr 93 07:42:58 PDT

DLSw SIG Members -

    Since I haven't seen any email on this list over the past few
    days, I'm not sure of its status.  I'll go ahead and assume the list
    is "open for business".

    One of the agreed-upon goals at our informal luncheon at the AIW
    was to produce a workable specification for Data Link Switching and
    to submit that specification to the IETF with the expectations that
    it would become a full Internet Standard fairly rapidly.  Also,
    since the process of running an open forum is a new venture for IBM
    and since Lee Rafalow stated that IBM is looking for assistance in
    this matter, I would like to propose that we establish a set of
    guidelines for the DLSw SIG.

    The model that is used by the IETF is probably too cumbersome for a
    well-focused effort like DLSw but it could be used as a starting
    point for customizing our own.  It is my understanding that the
    DLSw SIG is the first one to be created out of the AIW.  As such, a
    set of guidelines for running this SIG might have applicability
    outside our group.

    Below, I have attached two items from the IETF repository:
	(1) Guidelines to IETF Working Group Chair(s)
	(2) an example of the description for a single IETF working group
	    (osids in this case).

    I would like to have some discussion on how the DLSw SIG is run
    before we get too far down the road.

    Comments?  Suggestions?

-----------
Wayne Clark
cisco Systems, Inc.
[email-masked]
415/688-4627


		Guidelines to Working Group Chair(s)

Formation
---------

IETF working groups are the primary mechanism for the development of
IETF protocols, standards, and recommendations.

Before any working group is created, some preliminary work must be
done.  First, anyone interested in creating an IETF working group must
consult with the appropriate IETF Area Director under whose direction
the working group would fall, to confirm that creating a working group
is appropriate.

When determining if creating a working group is appropriate, the Area
Director will consider several issues:

   o Does the working group's activities overlap with those of another
     working group?  If so, it may still be appropriate to create
     another working group, but this question must be considered
     carefully.  Subdividing efforts often dilutes the available
     technical expertise.

   o Are there several people clearly interested in the working group's
     topic and willing to expend the effort to produce a result (such as
     an RFC)? There are situations where, while the problem the working
     group would tackle is interesting, there are not motivated bodies
     to make a working group effective.  Working groups require
     considerable manpower:  a chairman is needed to run meetings, an
     editor to edit authors' submissions, and authors to actually write
     text.  IETF experience suggests that these roles typically cannot
     all be handled by one person, four or five active members are
     typically required.  If the necessary manpower is lacking, the
     person interested in creating the working group might consider
     actually writing the RFC alone (an activity which usually is
     feasible), and then submitting it to the IETF for review, rather
     than creating a working group.

   o Are the issues that the working group plans to address important?
     Usually, if the issues are not important, then the necessary
     manpower will not exist, but the question is worth considering
     separately.

The Area Director, considering the above criterion will decide whether
to pursue the formation of the group through the chartering process.


The Charter
-----------

The formation of a working group requires an approved, written
charter.  This work statement should in about one page explain the
general purpose of the group, delimit its technical scope, enumerate a
set of goals and milestones together with timeframes for their
completion, and document various administrative points.

The content of the charter document is negotiated between a
prospective working group chair and the relevant area director.  When
both the prospective working group chair and the area director are
satisifed with the charter text, it can become the basis for forming a
working group. The charter document may be similarly renegotiated at
any time during the course of the working group's effort to reflect
the changing goals of the group.

Each charter consists of 5 sections.  These sections include both
static information about the group, the name, the chairmen, the
mailing lists, and the description.  The goals and milestones are part
of the IETF tracking system, and are designed to allow a degree of
project management and support.  They change periodically to reflect
the current status of the group.

   o Name:  A working group name should be reasonable descriptive.
     Additionally the group needs to find an 8 character ASCII acronym
     to reference the group in the IETF directories, mailing lists, and
     general documents.

   o Chair(s):  The working group may have one or two chair(s) to
     perform the administrative functions of the group.  It is strongly
     suggested that these persons have internet mail addresses.

   o Mailing Lists:  Most of the work of an IETF working group is
     conducted on Internet Mail exploder lists.  It is required that an
     IETF working group have a general discussion list.  A person needs
     to be designated the list service postmaster, usually through the
     list-request alias.  An archive should be maintained in a publicly
     FTPable place.  The [email-masked] should be added
     to the mailing list.  

     It is strongly recommended that the mailing list be on an
     connected IP host, to facilitate use of the SMTP  expansion
     command (EXPN) and to allow FTPaccess to the mail archives. If
     this is not possible, the archive and membership of the list must be
     made available by querying the list-request alias.

   o Description:  In 1-2 paragraphs, the focus and intent of the group
     should be set forth.  By reading this section alone, a person
     should be able to decide whether this group is relevant to their
     work.  

     Recognising the importance of security and network management in the
     Internet Architecture, this description of the work of the group must
     specifically address the impact in terms of security and management.

   o Goals and Milestones:  The working group should after the first
     meeting be able to enumerate a timetable for work.  While this
     often will change, it is indispensable to potential participants to
     be able to identify the critical moments for input.  This milestone
     list should be updated periodically to reflect progress.  Updated
     milestones should be submitted along with meeting minutes.

     Goals should be trackable items.  It is strongly recommended that
     each document the Working Group intends to produce be listed both
     with a date the first draft is expected to be installed as an 
     Internet Draft, and the date the Working Group intends to send
     the document to the IESG.


Announcement of the Group
-------------------------

After a charter is written, it should be submitted to Greg Vaudreuil
<[email-masked]> for recording.  He will enter the chartering
information into the IETF tracking database and send the charter to
the IESG-TECH mailing list for approval and comment.  Upon approval of
the charter, the Vaudreuil will send the charter to the IETF mailing list.

Duties of the Working Group Chair(s)
------------------------------------

The working group chair(s) have wide discretion in the conduct of
business.  The working group chair(s) have the responsibility to call
meetings of the working group, to make reports of the working group
activity available for public distribution, and otherwise advance the
group toward completion of the goals of the group as listed in the
charter.

Scheduling of Meetings
----------------------

The working group is expected to meet periodically to discuss and direct
future progress.  It is expected, but not required that every working
group meet at the trimester IETF plenary sessions.  Additionally,
interim meetings are encouraged by telephone conference, video
teleconference, or by actual face to face meetings.  Meetings should be
publicized as widely as possible, by announcing their time and location
on the working group mailing list, the IETF mailing list, and by putting
the date on the IETF Calendar by notifying Megan Davies
<[email-masked]>.

Meeting Policy
--------------

All working group actions should be public, and wide participation
should be encouraged.  An announcement of the date and time must be
sent to the working group mailing list and to Megan Davies
<[email-masked]> a reasonable time before the meeting.

After a period of open meetings, the working group chair may hold
executive (closed) meetings of the working group consisting of the
authors of a particular document and any serious reviewers.  This is
often necessary to make forward progress preparing a final document.
All work conducted in executive session must be made available for
review by any interested party.

Preparation of Minutes
----------------------

All working group sessions should be reported by making minutes
available.  It is expected that the working group chair(s) (or a
person designated by the working group chairman) submit minutes in
ASCII text to Megan Davies <[email-masked]> after each
meeting for publication in the IETF Proceedings, and for posting in
the IETF Directories.

These minutes should include the agenda for the meeting, an account of
the discussion including any decisions made, and a list of attendees.

Document Authorship
-------------------

The work of an IETF working group usually results in the publication of
one or more RFC's.  This series of documents are the journal of record
for the internet community.  A document can be written by an individual
in the working group or by the group as a whole with a designated
editor.  The designated author need not be the group chair(s).


Internet Drafts
---------------

The Internet Drafts directories are provided to the working groups as
a resource to post and disseminate early copies of any and all
documents of the working group.  This common repository is available
to all interested persons to facilitate wide review and comment.  It
is encouraged that draft documents be posted as soon as they become
reasonably stable.  Posting after they are in their final form reduces
the utility of this resource.  See the ``Guidelines to Authors of
Internet-Drafts'' for a more complete description and some basic
guidelines.

Termination of a Working Group
------------------------------

Working groups are typically chartered to accomplish a specific task.
After that task is complete, the group will be disbanded.  If after a
meeting a few times, it becomes evident that the group is unable to
complete the work outlined in the charter, the group with it's area
director can either 1) recharter to refocus on a smaller task, 2)
choose new chair(s), or 3) disband.

In those situations where the working group chairperson and the area
director disagree about the steps required to refocus the group or the
need to disband the group, the IESG will make a determination with
input from the area director and the working group chair(s)



Sample Charter

Internet Thumb Twiddling Protocol Working Group (ittp)

Chair(s):

     Jolly Goodtimer/ABC [email-masked]

Mailing Lists:
     General Discussion:  [email-masked]
     To Subscribe:  [email-masked]
     Mail Archive:  pub/[email-masked]

Description of Working Group:

     The Internet Thumb Twiddling working group is chartered to
     define a protocol for remotely twiddling thumbs over the
     Internet.  In defining this protocol, several questions must be
     addressed.  The use of remote or virtual thumbs must be more
     clearly defined.  The widespread usage of this protocol may
     generate large amounts of traffic, and the impact of such
     traffic needs to be analyze.  As with all modern protocols,
     provisions also must be made for the remote management of the
     protocol, as well as of the thumbs, and for authenticated
     twiddling.  Other security issues will be considered, but do
     not seem a priority at this time.  However, there might be a
     need to limit participant embarrassment at being a thumb
     twiddler, so that additional mechanisms will be needed to
     prevent disclosure.

Goals and Milestones:

May 1999      First IETF Meeting:  review and approve the charter
              making any changes deemed necessary.  Examine the
              particular functional needs for a TT protocol and define
              the scope of the service.  Begin work on a framework for
              the solution, if non-trivial.  Assign writing assignments
              for first draft of document.  First draft to be
              completed.

Sep 1999      Review first draft document, determine necessary
              revisions.  Follow up discussion will occur on mailing
              list.

Dec 1999      Make document an Internet Draft.  Continue revisions
              based on comments received at meeting and over e-mail.

Mar 2000      Fourth IETF meeting.  Review final draft and if OK, give
              to IESG for publication as RFC. Begin implementations.

Example of an IETF Working Group Description:
--------------------------------------------

OSI Directory Services (osids)

Charter 
 
Chair(s):
     Steve Kille  <[email-masked]>
 
Applications Area Director(s) 
     Russ Hobby  <[email-masked]>
     Erik Huizer  <[email-masked]>
 
Mailing lists: 
     General Discussion:[email-masked]
     To Subscribe:      [email-masked]
     Archive:           

Description of Working Group:

The OSI-DS Group works on issues relating to building an OSI Directory
Service using X.500 and its deployment on the Internet.  Whilst this
Group is not directly concerned with piloting, the focus is practical,
and technical work needed as a pre-requisite to deployment of an open
Directory will be considered.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 90 Jan 93  <draft-ietf-osids-friendlynaming-05.txt, .ps> 
                Using the OSI Directory to Achieve User Friendly Naming        
 
 Jan 92 Jan 93  <draft-ietf-osids-distnames-05.txt, .ps> 
                A String Representation of Distinguished Names                 
 
 Apr 92 Jan 93  <draft-ietf-osids-lightdirect-03.txt> 
                Lightweight Directory Access Protocol                          
 
 May 92 Aug 92  <draft-ietf-osids-syntaxes-01.txt> 
                The String Representation of Standard Attribute Syntaxes       
 
 Sep 92 New     <draft-ietf-osids-dsa-metrics-00.txt> 
                DSA Metrics